Thanks for the context and the link to #2876.

We’re still on 0.14.0 because our downstream crates are pinned to that release, and moving to 0.16+ is a larger migration we haven’t scheduled yet.

Pinning bincode in my own project doesn’t fix the publish issue in burn-core itself. When running cargo publish --dry-run -p burn-core (and for downstream crates), Cargo re-resolves dependencies without a lockfile and pulls in bincode 2.0.1, which then fails due to decode_borrowed_from_slice. That’s what motivated this PR for the 0.14.x line - to keep that release publishable until we can move to a newer Burn version.

If you’d prefer, I’m happy to switch this over to the API update (decode_from_slice) instead of the pin. Either approach on the 0.14 branch would unblock publishing.

Pinning is fine!

Pinning bincode in my own project doesn’t fix the publish issue in burn-core itself.

Ahhh yeah this is a fix in user-space (binary project), won't work for libs. Your users would have to apply this in their project.

Hopefully you can take advantage of the improvements in the latest releases soon! The upgrade is worth it. In the meantime, I'll try to trigger a patch publish for 0.14.1 later with the pinned rev.

That makes sense. Thanks for the clarification, and for taking a look.

Agreed on the distinction; a user-space pin helps binaries, but doesn’t address library publishability, which is what prompted this PR on the 0.14.x line. A patch publish with the pinned rev would fully unblock that.

Appreciate you triggering a 0.14.1 patch release. We’ll plan the upgrade to newer Burn releases once our downstream crates are ready. Looking forward to taking advantage of the improvements there.

@bigmark222 had to update some things in our tooling but just published a patch 0.14.1 for burn-core. All other crates remain at version 0.14.0. Just tested locally and burn correctly pulls the updated patch, there is no bincode build error.